Scrum, Kanban ve Scrumban: Yapay Zeka Destekli Ekipler

Yapay zeka asistanları artık kodun giderek büyüyen bir kısmını yazıyor, ama mühendislik liderleri hâlâ Scrum mı, Kanban mı, başka bir çevik çerçeve mi seçecekleri konusunda haftalarca tartışıyor, sonra başka bir şirketin törenlerini kopyalayıp neden hiçbir şeyin daha hızlı akmadığına şaşırıyor. Tuzak, çerçevenin ismini kararın kendisi sanmaktır; isim aslında dört geri besleme döngüsünün üstüne geçirilmiş bir kılıftır ve işi gerçekten yürüten o döngülerdir. Görüşüm şudur: yapay zeka destekli bir ekibin neredeyse hiç markalı bir metodolojiye ihtiyacı yoktur; ihtiyacı olan, işin nasıl aktığını, ne sıklıkla yeniden yön belirlediğinizi, paralelde ne kadar iş yürüdüğünü ve çıktının nasıl incelendiğini ayarlamaktır. Bu karar merceği, bir sonraki çerçeve modasından sonra da geçerli kalır ve yapay zekanın darboğazı kod yazmaktan uzaklaştırdığını hesaba katar.

Karar, ekibi yöneten kişiye aittir: mühendislik yöneticileri, kurucular, teknik liderler. Aşağıda tören reçetesi de kod da yok; yalnızca döngü ayarları ve arkasındaki muhakeme var. Argüman birincil kaynaklara (Scrum Guide, Kanban Guide, Çevik prensipler, DORA araştırması) ve her döngünün nereye ayarlanması gerektiğine dair savunulabilir bir varsayılana dayanıyor.

Her çerçevenin sardığı dört döngü

Markalamayı kenara koyduğunuzda, popüler çevik çerçevelerin hepsi aynı dört döngüyü ayarlıyor. Bunları açıkça adlandıralım, çünkü bundan sonrası üstteki törenleri değil bu döngüleri ayarlıyor.

Akış, bir iş biriminin fikirden sevkiyata nasıl ilerlediğidir. Onu bir panoda görünür kılar, lead time ve cycle time ile ölçersiniz. DORA’nın teslimat metrikleri burada kalıcı tanımları verir (değişiklik lead time’ı, dağıtım sıklığı, değişiklik başarısızlık oranı, başarısız dağıtımdan kurtulma süresi ve yeniden çalışma oranı), throughput ve kararsızlık olarak ikiye ayrılır. Çerçeveye dikkat: bunlar DORA’nın teslimat metrikleridir, “dört anahtar” değil; model yeniden çalışma oranını ekledi ve kurtulma süresini yeniden adlandırdı, yani eski etiket artık güncel değil.

Yeniden yön belirleme temposu, ekibin ne sıklıkla durup incelediği ve yeniden planladığıdır. Scrum bunu sabit uzunlukta bir Sprint olarak paketler, “one month or less” (bir ay veya daha az), Scrum Guide’ın deyimiyle “ensure inspection and adaptation of progress toward a Product Goal at least every calendar month” amacıyla var olan kalp atışıdır. Kanban aynı döngüyü sürekli akış artı bilinçli tempolar ve geri besleme döngüleri olarak paketler, sabit bir yineleme olmadan. Aynı döngü, farklı ayar.

WIP limitleri, yeni işler başlamadan önce işlerin bitmesi için devam eden işi sınırlar. Bu Kanban’ın özüdür: Kanban Guide “effective systems focus more on flow of work and less on worker utilization” der ve bir çekme sistemi üzerinden “limit the WIP to balance utilization and still ensure the flow of work” gerektiğini söyler. Scrum, WIP kontrolünü açık bir limit olarak değil, Sprint Backlog üzerinden örtük şekilde taşır.

İnceleme, bitmiş çıktının “tamamlandı” sayılmadan önce nasıl denetlendiğidir. Yapay zeka asistanlarından önce bu, kod incelemesi artı QA demekti. Asistanlar uygulamanın giderek büyüyen bir kısmını üretirken inceleme döngüsü daha fazla ağırlık taşıyor, çünkü üretmek ucuzladı ama doğrulamak ucuzlamadı. DORA’nın kendisi, kod incelemelerinin ne kadar sürdüğünü öncü bir gösterge olarak ölçmeyi öneriyor; bu, ilerideki yapay zeka noktası için işe yarayan bir bağlantı.

Scrum, Kanban ve geri kalanların ardındaki tek motor

Dört döngüyü gördüğünüzde, popüler çerçeveler rakip felsefeler gibi görünmeyi bırakıp birer hazır ayar gibi görünmeye başlar.

Scrum, yeniden yön belirlemeyi taahhüt edilmiş bir iş yığınıyla birlikte paketleyen sabit bir tempo (Sprint) belirler. Üç sorumluluk (Product Owner, Scrum Master, Developers) ve beş etkinlik döngüleri resmileştirir. Scrum Guide ne olduğu konusunda alışılmadık derecede açık sözlüdür: Scrum’ı “a lightweight framework” olarak adlandırır, “purposefully incomplete, only defining the parts required to implement Scrum theory” der ve şunu ekler: “Scrum wraps around existing practices or renders them unnecessary.” Bu son cümle, tüm argümanın küçültülmüş halidir. Scrum’ın yazarları bile onu uygulanacak bir kurallar kitabı değil, döngülerin üstündeki ince bir kabuk olarak çerçeveler.

Kanban, açık WIP limitleri, bir çekme sistemi ve geri bildirim için planlı tempolarla sürekli akış belirler. Genel pratikleri bir ayar kontrol listesi gibi okunur: işi görselleştir, WIP’i sınırla, akışı yönet, politikaları açık hale getir, geri besleme döngüleri uygula ve birlikte iyileştir. Başlangıç talimatı “start with what you do now” (şu an yaptığınızla başlayın), ki bu bir kurallar kitabını benimsemenin tam tersidir.

Diğer agile metodolojiler de aynı hikâyeyi anlatır. Scrumban, bir Scrum ekibini akışa doğru çekmek için bir geçiş tekniği olarak başladı, üçüncü bir marka olarak değil; Extreme Programming, sıkı mühendislik döngülerini (eşli programlama, test güdümlü geliştirme, sürekli entegrasyon) aynı akış-ve-inceleme omurgasının üstüne sarar; SAFe ve LeSS gibi ölçekleme çerçeveleri ise çoğunlukla birçok ekip arasına koordinasyon döngüleri ekler. Her biri aynı dört kadranın bir hazır ayarıdır. Her biri ayrıca, bir ayar değil bir kimlik olarak benimsendiği anda “döngü yerine isim” hatasına savrulur; bir metot bağımsız bir varış noktası olarak pazarlandığında tam olarak bu yaşanır.

Uygulayıcı literatürü aynı sonuca yapay zeka tabloya girmeden çok önce ulaştı. Kniberg ve Skarin’in klasik karşılaştırması Scrum ve Kanban’ı rakip inanç sistemleri olarak değil, aynı kadranları farklı varsayılanlarla ayarlayan araçlar olarak ele alır. Karar her zaman döngü ayarlarıyla ilgiliydi.

Yapay Zeka Etkisiyle Değişen Kısıtlar

Yapay zeka destekli bir ekip yine aynı dört döngüyü yürütür; asistan beşinci bir döngü eklemez, yalnızca kısıtın nerede olduğunu kaydırır. Bu kayma, liderlerin sürekli ters anladığı iki sonuç doğurur.

Darboğaz kod yazmaktan uzaklaşır. Bir asistan uygulama süresini sıkıştırıyorsa, uygulamayı (ucuzlayan kısmı) optimize etmek pek fayda sağlamaz. Kısıt inceleme, entegrasyon ve ne inşa edileceğine karar vermeye kayar. Somut olarak bu, tören temposunun değil, WIP ve inceleme döngülerinin yatırımı hak ettiği anlamına gelir. Hiçbir zaman darboğaz olmamış kısmı hızlandırmak boşa harcanan harekettir.

Toplu iş boyutu eşiktir ve varsayılan olarak yanlış yöne iter. Ucuz üretim daha fazla kod yazmayı kolaylaştırır, bu da değişiklik setlerini büyütür ve daha büyük değişiklik setleri DORA’nın tutarlı risk sinyalidir. DORA teslimat rehberi açıktır: “Teams should make each change as small as possible to make the delivery process fast and stable.” Yani daha hızlı üretim, daha uzun sprintleri değil, daha küçük toplu işleri ve daha sıkı incelemeyi gerektirir. “Yapay zeka bizi hızlandırdı diye sprint’i uzatalım” içgüdüsü tam olarak yanlış değişkeni optimize eder.

Liderler verimlilik manşetlerine de direnmeli, çünkü kanıtlar gerçekten çelişiyor. Bu çelişki aşağıda kendi bölümünü hak edecek kadar önemli; şimdilik pratik okuma daha basit. Daha ucuz üretim otomatik olarak daha hızlı teslimat anlamına gelmez, yani inceleme ve akış döngüleri yapay zeka altında daha az değil daha fazla önemlidir ve metodolojinin ismi eskisinden bile daha az önemlidir.

Önerilen varsayılan: döngüleri ayarlayın, sürekli akışla başlayın

İşte duruş, bir marka olarak değil bir ayar olarak ifade edilmiş hali. Döngüleri bağlamınıza göre ayarlayın ve isimli bir çerçeveyi benimsemeden önce sürekli akış varsayılanlarına yönelin: işi görselleştirin, WIP’i sınırlayın, kısa bir yeniden yön belirleme temposu tutun ve inceleme döngüsünü güçlendirin.

Çoğu küçük-orta ölçekli yapay zeka destekli ekip için, açık bir inceleme döngüsüne sahip hafif, Kanban tadında bir akış, törensel Scrum’ı geride bırakır. Bu, yapay zeka iş akışının zaten atlamayı ucuzlaştırdığı toplu iş ve tahmin yükünü kaldırır ve dikkati yapay zekanın yeni yük taşıyıcı yaptığı döngüye (incelemeye) yöneltir. Bu “Kanban kazanır” demek değildir. Bu “isim seçmeyi bırakın; döngü ayarlarını seçin ve şu ayardan başlayın” demektir.

Scrum’ın sabit temposu varsayılan değil, geçersiz kılma durumudur. Ekibin dışsal bir taahhüt ritmine ihtiyacı olduğunda yükünü hak eder: programlı paydaş demoları, düzenlemeye tabi bir sürüm treni ya da isimli etkinliklerin iskelesinden fayda gören kıdem açısından genç bir ekip. Aşağıdaki karar ağacı varsayılanda köklenir ve yalnızca bir geçersiz kılmanın gerçekten karşılığını verdiği yerlerde dallanır.

Bir geçersiz kılma daha adlandırmayı hak ediyor. Halihazırda ağır bir çerçeve yürütüyorsanız ve törenler tiyatro gibi geliyorsa, daha hafif metodu bir geçiş olarak ele alın, takılacak yeni bir rozet olarak değil. Scrumban aslında tam da buydu: bir Scrum ekibini akışa doğru çekmenin bir yolu. Hedef durum, hiçbir hedefi olmayan kalıcı bir hibrit değil, ayarlanmış bir döngü kümesidir.

Trade-off’lar, dürüstçe adlandırılmış

Her ayarın bir başarısızlık modu vardır ve onu baştan adlandırmak önerinin bir parçasıdır.

Ayar	Kazandığınız	Dikkat edilecek başarısızlık modu
Sürekli akış varsayılanı	Düşük tören yükü, dikkat akış ve incelemede	Görünmez önceliklendirme ve inceleme tempolarını bilinçli planlamadıkça doğal bir “dur ve düşün” anının olmaması; tepkisel yangın söndürmeye kayabilir
Scrum sabit tempo	Öngörülebilir ritim, yerleşik bir retrospektif, dışsal bir taahhüt anı	Tahmin tiyatrosu, velocity oyunlama, toplu iş gecikmeleri, kendi hatırına tutulan tören
Geçiş olarak daha hafif bir metot (ör. Scrumban)	Ağır törenden geçişi kolaylaştırır	Hedefi olmayan kalıcı bir varış noktası olarak ele alınırsa “iki dünyanın da kötüsü”
Yapay zeka inceleme yatırımı	Yeni risk yüzeyini yakalar (yapay zeka kaynaklı hatalar, uydurma API’ler)	İnceleyen yükü kısıt haline gelir, yani onu bedava saymak yerine adlandırın ve kadro ayırın

Döngüleri önemli kılan çelişki: yapay zeka teslimatı gerçekten hızlandırıyor mu?

Burası işin can alıcı noktası, çünkü dürüst yanıt “kanıtlar çelişiyor”dur ve bu çelişki, bir çerçeve peşinde koşmak yerine inceleme ve akış döngülerini ayarlamak için en güçlü argümandır. Üç inanılır kaynak farklı yönlere işaret ediyor ve her biri bir liderin aynı anda tutması gereken çekinceler taşıyor.

DORA 2024 bir kazanım değil, bir trade-off buldu. Accelerate State of DevOps Report, yapay zeka benimsemenin bireysel verimliliği, akışı ve iş tatminini artırdığını, ancak yapay zeka benimsemedeki birim artış başına teslimat throughput’unda yaklaşık %1,5 düşüş ve teslimat kararlılığında yaklaşık %7,2 düşüş tahmin ettiğini bildirdi. Çekince yöntemde: bu, kontrollü bir deneme değil, çok sayıda ekip üzerinden kendi beyanına dayalı bir anket korelasyonudur; yani nedeni kanıtlamaz, ilişkiyi gösterir. DORA’nın okuması mekaniktir: yapay zeka daha fazla kod yazmayı kolaylaştırır, toplu iş boyutu büyür, daha büyük değişiklik setleri daha fazla risk taşır ve temeller (küçük toplu işler, sağlam test) hala geçerlidir. 2025 takip baskısı, “State of AI-assisted Software Development,” yapay zekayı bir yükselteç olarak yeniden çerçeveler. Throughput yükselebilir, ancak ekibin güçlü testi, olgun sürüm kontrolü ve hızlı geri besleme döngüleri yoksa kararlılık aşağı akışta bozulur. Çözüm olarak yine küçük toplu işlere işaret eder. Her iki baskı da buradaki argüman açısından aynı yere varıyor. Yapay zeka, döngüleri zaten ayarlı olan ekipleri ödüllendirir ve döngüleri gevşek olan ekipleri cezalandırır.

METR’nin rastgele denemesi, yapay zekanın uzmanları yavaşlattığını buldu. Kendi depolarında çalışan 16 deneyimli açık kaynak geliştiricisiyle yapılan bir rastgele kontrollü denemede, erken 2025 yapay zeka araçlarını kullanmak işlerini yaklaşık %19 daha uzun sürdürdü, oysa aynı geliştiriciler yaklaşık %20 daha hızlı olduklarına inanıyordu. Bu algı farkı, bir liderin göz ardı edemeyeceği kısımdır: bildirilen hız teslimat değildir. Çekinceler gerçektir ve METR bunları belirtir: kümelenmiş standart hatalarla küçük örneklem, sıfırdan değil tanıdık kod tabanlarında çalışan uzman geliştiriciler ve sürekli değişen erken 2025 araçları. Bu, evrensel bir yasa değil, tek bir ortamın anlık görüntüsüdür.

GitHub’ın tedarikçi çalışması, sınırlı bir görevde büyük bir hızlanma buldu. Bir JavaScript HTTP sunucusu yazan 95 profesyonel geliştiriciyle yapılan kontrollü bir deneyde, Copilot kullanan grup yaklaşık %55 daha hızlı bitirdi, %95 güven aralığı %21 ila %89. Çekinceler de aynı derecede yük taşıyor ve eksiksiz belirtmeye değer: çalışma tedarikçi tarafından yürütüldü, yani bir çıkar çatışması var; görev belirsiz mimari iş değil, tek ve iyi sınırlanmış bir sıfırdan problemdi; ve başarı oranındaki fark istatistiksel olarak anlamlı değildi. Dar bir durum için güçlü bir kanıt.

Üçünü bir arada tutun ve ders “yapay zeka iyidir” ya da “yapay zeka kötüdür” değildir. Ders, var olduğu yerde hızlanmanın üretimde yoğunlaştığı, oysa teslimatın toplu iş boyutuna, entegrasyona ve incelemeye bağlı olduğudur. Daha ucuz kod yazmak tek başına daha hızlı sevkiyat satın almaz. Dikkatinizi yapay zekanın isminden bile daha az önemli kıldığı çerçeve adına değil, yapay zekanın zorladığı döngülere (WIP ve incelemeye) yöneltmenin tüm gerekçesi budur.

Adlandırmaya değer daha küçük ikinci bir anlaşmazlık var, çünkü liderlerin Scrum’ı nasıl okuduğunu şekillendiriyor. Scrum Guide, Scrum’ı hafif ve bilinçli olarak eksik diye çerçeveler; akış ve post-agile uygulayıcıları, pratikteki Scrum’ın törene dönüşüp katılaştığını savunur ve Ladas’ın kendisi “could not tolerate another round of sprint planning” yazdı ve Scrum tahmin yaklaşımını bir “bad practice” olarak değerlendirdi. Ekibe bağlı olarak ikisi de doğru. Test, hangi kampın haklı olduğu değildir; her törenin sizin bağlamınızda hala bir döngüye hizmet edip etmediğidir.

Yaygın tuzaklar

Bunlar, liderler döngüler yerine kılıfı optimize ettiğinde ortaya çıkan başarısızlık kalıplarıdır.

• Törenleri kimlik olarak benimsemek. “Biz Scrum ekibiyiz” bir döngü ayarı değildir. Her ritüel için hizmet ettiği döngüyü adlandırın; hiçbiri yoksa onu kesin.
• Katılımı ve story point’leri başarı olarak izlemek. Tören uyumu akış değildir. DORA’nın teslimat metriklerini (değişiklik lead time’ı, dağıtım sıklığı, değişiklik başarısızlık oranı) artı bir DORA metriği değil bir pano metriği olan WIP’i izleyin.
• “Yapay zeka bizi hızlandırdı” diye sprintleri uzatmak. Daha hızlı üretim, daha uzun döngüleri değil, daha küçük toplu işleri ve daha sıkı incelemeyi gerektirir. Bu, yapay zeka çağının en yaygın hatasıdır.
• Yapay zeka verimlilik manşetlerini kesinleşmiş saymak. Çalışmalar çelişiyor. Onları aktarın, çekinceleri tutun ve bir tedarikçinin iddiası yerine kendi akış metriklerinizi izleyin.
• Başka bir şirketin sürecini olduğu gibi kopyalamak. Döngü niyetini kopyalayın, sonra kendi döngü parametrelerinizi belirleyin. Başka bir ekibin varsayılanları başka bir ekibin bağlamını kodlar.

Varsayılanın geçerli olmadığı durumlar

Varsayılan, çoğu küçük-orta ölçekli yapay zeka destekli ekip için geçerlidir: dört döngüyü ayarlayın, hafif sürekli akıştan başlayın ve serbest kalan dikkati yapay zekanın yeni yük taşıyıcı yaptığı inceleme döngüsüne yöneltin. Dışsal bir tarafa öngörülebilir bir ritim borçlu olduğunuzda, yeni kurulmuş veya kıdem açısından genç bir ekibin iskeleye ihtiyacı olduğunda ya da düzenlemeye tabi bir sürüm treni temposu sizin yerinize belirlediğinde Scrum’ın sabit temposuna yönelin. Scrumban gibi bir geçiş metoduna yalnızca bir köprü olarak, aklınızda bir hedef durumla yönelin. Her durumda karar birimi bir marka değil, bir döngü ayarıdır.

Tek bir sonraki adım küçüktür. Şu an yürüttüğünüz bir töreni seçin, hizmet ettiği döngüyü adlandırın ve hiçbirine hizmet etmiyorsa bu hafta onu bırakın. O tek eylem, akışınız için herhangi bir çerçeve benimsemesinden daha fazlasını yapar.

Kaynaklar

• The 2020 Scrum Guide - Scrum etkinlikleri, üç sorumluluk ve tezin dayandığı “lightweight” ile “purposefully incomplete” çerçevelemesi için Schwaber ve Sutherland’dan birincil kaynak.
• The Official Guide to The Kanban Method (Kanban University) - Kanban’ın genel pratikleri (görselleştir, WIP’i sınırla, akışı yönet, politikaları açık hale getir, geri besleme döngüleri) ve çekme sistemi gerekçesi için birincil kaynak.
• Principles behind the Agile Manifesto - On iki prensip; “the team reflects, then tunes and adjusts its behavior” ve “maximizing the amount of work not done” döngü-tören argümanını destekler.
• DORA: Software delivery performance metrics - Değişiklik lead time’ı, dağıtım sıklığı, değişiklik başarısızlık oranı, başarısız dağıtımdan kurtulma süresi ve yeniden çalışma oranının tanımları, artı küçük toplu iş rehberi.
• DORA: Accelerate State of DevOps Report 2024 - Yapay zeka trade-off bulgusu (bireysel verimlilik artar; teslimat throughput’u ve kararlılığı düşer) ve toplu iş boyutu mekanizması.
• DORA: State of AI-assisted Software Development 2025 - Yapay zekayı mevcut mühendislik güçlü ve zayıf yanlarının bir yükselteci olarak çerçeveleyen güncel takip baskısı, çözüm olarak küçük toplu işlerle.
• METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity - Deneyimli geliştiricilerin tanıdık depolarda yapay zeka ile yaklaşık %19 daha yavaş olduğunu bulan rastgele kontrollü deneme, artı algı farkı çekincesi.
• GitHub: Quantifying GitHub Copilot’s impact on developer productivity and happiness - %55 daha hızlı sonucu gösteren tedarikçi kontrollü deneyi, burada çıkar çatışması ve tek görev çekinceleriyle aktarılıyor. Makale: arXiv 2302.06590.
• Kniberg ve Skarin: Kanban and Scrum, Making the Most of Both - İki yaklaşımı karşılaştıran uygulayıcı klasiği; ikisinin aynı kadranları farklı varsayılanlarla ayarladığı görüşünü destekler.
• Corey Ladas: Remarks on the Original Scrumban Essay - Scrumban’ın mucidi kendi sözleriyle: sınırlı WIP, sürekli teslimat ve olay güdümlü planlamayla Scrum’ın bir geçişi ve modernizasyonu olarak kökeni.
• Scrum Alliance: What is Scrumban? - Scrumban’ı bağımsız bir çerçeve olarak pazarlama eğilimini, bu yazının eleştirdiği tam o “isim döngüden uzun yaşar” kalıbını gösterir.